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Abstract 


This document provides principles for the operation of Internet 
Assigned Numbers Authority (IANA) registries. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Architecture Board (IAB) 
and represents information that the IAB has deemed valuable to 
provide for permanent record. It represents the consensus of the 
Internet Architecture Board (IAB). Documents approved for 
publication by the IAB are not a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7500. 


Copyright Notice 


Copyright (c) 2015 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. 
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1. Introduction 


The Internet Engineering Task Force (IETF) and its predecessors have 
traditionally separated the publication of protocol specifications in 
immutable Request for Comments (RFCs) and the registries containing 
protocol parameters. Traditionally, the registries are maintained by 
a set of functions known collectively as the Internet Assigned 
Numbers Authority (IANA). Dating back to the earliest days of the 
Internet, specification publication and the registry operations were 
tightly coupled: Jon Postel of the Information Sciences Institute 
(ISI) of the University of Southern California (USC) was responsible 
for both RFC publication and IANA registry operation. This tight 
coupling had advantages, but it was never a requirement. Indeed, 
today the RFC Editor and IANA registry operation are provided by 
different entities. 


Internet registries are critical to the operation of the Internet, 
because they provide a definitive record of the value and meaning of 
identifiers that protocols use when communicating with each other. 
Almost every Internet protocol makes use of registries in some form. 
At the time of writing, the IANA maintains more than two thousand 
protocol parameter registries. 


Internet registries hold protocol identifiers consisting of constants 
and other well-known values used by Internet protocols. These values 
can be numbers, strings, addresses, and so on. They are uniquely 
assigned for one particular purpose or use. Identifiers can be 
maintained in a central list (such as a list of cryptographic 
algorithms) or they can be hierarchically allocated and assigned by 
separate entities at different points in the hierarchy (such as IP 
addresses and domain names). To maximize trust and usefulness of the 
IANA registries, the principles in this document should be taken into 
consideration for centralized registries as well as hierarchically 
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delegated registries. In hierarchically delegated registries, 
entries nearest to top level have broad scope, but lower-level 
entries have narrow scope. The Internet Architecture Board (IAB) 
will encourage support for these principles in all delegations of 
Internet identifiers. 


The registry system is built on trust and mutual cooperation. The 
use of the registries is voluntary and is not enforced by mandates or 
certification policies. While the use of registries is voluntary, it 
is noted that the success of the Internet creates enormous pressure 
to use Internet protocols and the identifier registries associated 
with them. 


This document provides principles for the operation of IANA 
registries, ensuring that protocol identifiers have consistent 
meanings and interpretations across all implementations and 
deployments, and thus providing the necessary trust in the IANA 
registries. 


2. Principles for the Operation of IANA Registries 
The following key principles underscore the successful functioning of 
the IANA registries, and they provide a foundation for trust in those 


registries: 


Ensure Uniqueness: The same protocol identifier must not be used for 
more than one purpose. 


Stable: Protocol identifier assignment must be lasting. 


Predictable: The process for making assignments must not include 
unexpected steps. 


Public: The protocol identifiers must be made available in well- 
known locations in a manner that makes them freely available to 
everyone. 


Open: The process that sets the policy for protocol identifier 
assignment and registration must be open to all interested 


parties. 


Transparent: The protocol registries and their associated policies 
should be developed in a transparent manner. 


Accountable: Registry policy development and registry operations 
need to be accountable to the affected community. 
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3. Discussion 


The principles discussed in Section 2 provide trust and confidence in 
the IANA registries. This section expands on these principles. 


3.1. Ensuring Uniqueness, Stability, and Predictability 


Protocol identifier assignment and registration must be unique, 
stable, and predictable. Developers, vendors, customers, and users 
depend on the registries for unique protocol identifiers that are 
assigned in a stable and predictable manner. 


A protocol identifier may only be reassigned for a different purpose 
after due consideration of the impact of such a reassignment, and if 
possible, with the consent of the original assignee. 


Recognizing that some assignments involve judgment, such as those 
involving a designated expert [RFC5226], a predictable process does 
not require completion in a predetermined number of days. Rather, it 
means that no unexpected steps are introduced in the process of 
making an assignment. 


3.2. Public 


Once assigned, the protocol identifiers must be made available ina 
manner that makes them freely available to everyone without 
restrictions. The use of a consistent publication location builds 
confidence in the registry. This does not mean that the publication 
location can never change, but it does mean that it must change 
infrequently and only after adequate prior notice. 


3.3. Open and Transparent 


The process that sets the policy for protocol identifier assignment 
and registration must be open to all interested parties and operate 
in a transparent manner. 


When a registry is established, a policy is set for the addition of 
new entries and the updating of existing entries. While making 
additions and modifications, the registry operator may expose 
instances where policies lack clarity. When this occurs, the 
registry operator should provide helpful feedback to allow those 
policies to be improved. In addition, the registry operator not 
being involved in establishing registry policy avoids the risks 
associated with (perceptions of) favoritism and unfairness. 
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Recognizing that some assignments involve judgment, such as those 
involving a designated expert [RFC5226], the recommendations by 
designated experts must be visible to the public to the maximum 
extent possible and subject to challenge or appeal. 


3.4. Accountable 


The process that sets the policy for IANA registries and the 
operation of the registries must be accountable to the parties that 
rely on the protocol identifiers. Oversight is needed to ensure 
these are properly serving the affected community. 


In practice, accountability mechanisms for the registry operator may 
be defined by contract, memoranda of understanding, or service level 
agreements (SLAs). An oversight body uses these mechanisms to ensure 
that the registry operator is meeting the needs of the affected 
community. The oversight body is held accountable to the affected 
community by vastly different mechanisms, for instance recall and 
appeal processes. 


For protocol parameters [RFC6220], the general oversight of the IANA 
function is performed by the IAB as a chartered responsibility from 
[RFC2850]. In addition, the IETF Administrative Oversight Committee 
(IAOC), a body responsible for IETF administrative and financial 
matters [BCP101], maintains an SLA with the current registry 
operator, the Internet Corporation for Assigned names and Numbers 
(ICANN), thereby specifying the operational requirements with respect 
to the coordination, maintenance, and publication of the protocol 
parameter registries. Both the IAB and the IAOC are accountable to 
the larger Internet community and are being held accountable through 
the IETF Nomcom process [BCP10]. 


For the Internet Number Registries [RFC7249], oversight is performed 
by the Regional Internet Registries (RIRs) as described RFC 7020 
[RFC7020]. The RIRs are member-based organizations, and they are 
accountable to the affected community by elected governance boards. 
Furthermore, per agreement between the RIRs and ICANN, the policy 
development for the global IANA number registries is coordinated by a 
community-elected number council and subject to process review before 
ratification by the ICANN Board of Trustees [ASOMOU]. 


4. Security Considerations 
Internet Registries are critical to elements of Internet security. 


The principles described in this document are necessary for the 
Internet community to place trust in the IANA registries. 
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